The Day My Lawyer Friend Learnt To Speak Data
10 March 2026 · Loïc Ribet · 12 min · Updated: 09 March 2026
Today, I’d like to share a little story about my virtual friend, Tom the lawyer, to help you learn some basic data vocabulary.
Tom is a senior lawyer specialised in international contracts, widely recognised for his sharp legal mind and strategic finesse. Meticulous down to the smallest clause, his clients adore him and his reputation is impeccable. But behind this flawless professional façade lies a dangerous well-kept secret: he is hopeless with technology.

One morning, without knocking, his managing partner pushes open the office door and walks in. He does not smile. He sits down slowly.
“Tom… we have a problem.”
Tom removes his feet from the desk.
“I’m listening.”

“Our litigation department just lost a major case concerning a contract we drafted three years ago. The board meets tomorrow. I need to be ready.”
Tom straightens in his chair.
“I need some basic statistics. A list of all contracts drafted over the last five years by jurisdiction and by client, to assess our exposure to risk.”
A pause.
“I need it by tomorrow. 10am.”
And just like that, the managing partner leaves.
Silence.
Tom freezes.
He knows the contracts exist. He drafted many of them and reviewed the rest. But an overview of all contracts, categorised by jurisdiction and client, in less than 24 hours? Impossible. They are everywhere. Folders. Cabinets. Email attachments. Shared drives.

Tom slowly reaches for his brand-new phone, the latest model, outrageously overpriced, and almost entirely useless in this situation.
He calls a friend.
“Hi Loïc.”
“Tom! Long time. You sound worried. What's happened?”
“I need your help. I’ve been asked to produce a list of all our contracts per jurisdiction and per client.”
“That’s easy. Open your master list and apply filters.”, Loïc replies.
Silence.
“We don’t have a master list.”
“… Of course you don’t. And I’ve been telling you for years that data is an asset.”
“I know… I know. But you know how it is. I never really prioritised it. I usually keep everything in my head.”
“Yes. That works… until it doesn’t.”
“What can I do now? I don’t know where to start. You’re my only hope.”

Loïc laughs softly.
“Alright. Let’s start simple. First step, gather every contract you’ve reviewed in the last five years. Print them if necessary and put them all on your desk.”
“All of them?”
“Yes, trust me. Call me back when you are done.”
A few hours later, Tom calls back.

“All the contracts are on my beautiful wooden desk.”
"What type of wood is it?"
"Mahogany."
"Solid choice. Unlike your data strategy."
"Ha ha! Seriously, what do I do now?"
“Now look at your desk carefully. What do you see?”
“I see a lot of legal contracts.”
“And what do they contain?”
Tom pauses.

“Clauses. Names. Dates. Signatures.”
“These are facts or pieces of information, right?”, Loïc replies.
“Yes?”
“These facts are displayed on a piece of paper through symbols, letters, numbers, right?”
“What's your point?”
“Now you know what data is!”
“Oh… I think I see what you mean. Facts exist regardless of whether they are known or recorded. But when we represent them, in a document, a spreadsheet, or a digital system, that’s what we call data.”
“Exactly,” says Loïc. “If you have a fever, that’s a fact. When you measure your temperature with a thermometer and record 39°C, that number becomes data. Something you can store, analyse, and compare.”
He continues:
“A governing law. A counterparty name. A renewal date. They are all data. In fact, almost anything around you, including information within a contract, can be data. And by the way, I have a fun fact for you.”
“Go ahead.”
“Since you’re a lawyer, you’re used to Latin expressions. Data is actually a Latin word. Technically, in Latin it’s plural. The singular is datum.”
“Interesting! But what's the point of knowing all of this?"
“Alright,” says Loïc. “So you have data in front of you. But you actually have two problems.”
“Go on.”
“First, your data lives on paper. You can’t filter it. You can’t sort it. You can’t analyse it quickly.”
Tom looks at the piles.
“That’s painfully accurate.”
“Second,” Loïc continues, “even if you scanned everything, the data is buried inside documents. It’s not organised in a consistent structure. In other words, what you have is unstructured data.”
“And what I need is...?”
“You need to capture that data in a structured format, in a system where each piece of information has a defined place. Once it’s structured, you can sort it, compare it, and extract meaningful insights.”
“Yes, That's exactly what I need right now. But wait. Couldn’t I just use AI to extract everything automatically?”
Loïc sighs dramatically.
“Easy Tom, one revolution at a time...”
“So AI is not the solution?”
“AI is powerful. But AI works best when your foundations are solid and when you know what you need and want. If you don’t understand what you want to extract, you’ll just automate confusion.”
Tom leans back.
“So before using AI… I need to understand my data.”
“Exactly. One day I will teach you AI don't worry.”
“You are right. I'm listening.”
“What is the main thing you want to record right now?”
“Contracts”
“Yes. Contract is the 'Thing', the 'Concept' from the world you want to track. Some people also call this an Entity.”
“Ok, one entity must be 'one Thing' from the world and it has nothing to do with 'legal entities'.”
“Yes, nothing at all. Except that legal entities themselves can also be part of a distinct entity 'Legal Entity'. Same as Clients, Jurisdictions, Laws, Regulations etc.”
“Wow, I get it.”
“Ok, now imagine a box of Contracts. This box represents the Entity 'Contracts' and we are going to put this data into a structure and record it digitally.”

“Take one contract in your hand,” Loïc says.
Tom picks one up.
“What information does it contain?”
“Contract name, Names of parties, Signature date, several legal clauses.”
“These,” says Loïc, “are attributes of each contract (or of the entity 'Contract'). Can you think of other attributes that relate to each contract but that are not written directly in them?”
“I'm not sure I understand the question.”
“Can you think of characteristics or properties that hold information relating to the contract but that is not specifically written as such in the contract? As a hint, think of some categories in which you could classify the contract.”
“Ah, I see! For instance, it is not specifically written but this contract is a Distribution Agreement; it remains in force, or we could say that it's currently valid.”
“Perfect, these are also attributes of the contract. Okay, so far, what do we have?”
“We have an Entity 'Contracts'; and some attributes for each contract.”
“Yes. Now, let's create a prototype of list. On your computer, create a simple spreadsheet that you will call Contracts for instance. And this list has some columns. Each column will correspond to an attribute. And you can add in this list your first line which will be the contract you have in hands. Add the columns 'Contract reference', 'Counterparty 1', 'Counterparty 2', Type of contract, Signature date, Status.”
“Okay, let me do this.”
“Take your time.”
Tom creates a table in a spreadsheet and adds one contract as they speak.
“Ok it's done. I have created the list with one contract.”

“Ok, so you have learnt a few things here. First, what you have created is a list, some people call it a Table. Each column, as we say, represents an attribute of the contracts. Some people call them Fields.”
“And let me guess, each line represents a contract. And we call each line a...?”
“...A Record, or an Entry, or even Item.”
“And, is there a name for a single unit of data?”
“Yes, it would simply be called a Value. Some people can also call that a data point, but there is a subtle difference between the two terms that is not worth understanding today.”
“I see. Let me try to memorise all of this. That's a lot of words.”

“Yes, there is lots of synonyms but really there are only a couple of terms to understand.”
“Ok I think I can picture it. So I guess I need to input all of my contracts right?”
“Yes, that's correct. You probably won't sleep tonight but that will be worth it.”
“Can I ask you a question?” asks Loic.
“Yes, of course.”
“You see, you have two attributes for counterparties?”
“Yes?”
“I guess some of those counterparties are also your clients.”
“Yes, that's correct.”
“Let me ask you a question. What would happen if you have several contracts for the same client?”
“I would enter several records, one for each contract.”
“Yes. And you would enter the name of the counterparty twice in your Contracts Table right?”
“Yes I guess so.”
“What if in 6 months, this counterparty changes its name?”
“I would have to modify all the entries of the Contracts table that involves this client.”
“That’s correct. But you see, this isn’t a good solution. Legally speaking, the first contract was signed under the old name. And secondly, you’d potentially have to update dozens of records.”
“Yes, that does not sound right then.”
“Yes, there is an easy solution that we can discuss in more details later, but I want you to understand the main concept now. Let's create a new entity "Counterparty". Make a mental image of a new box that represents all the counterparties written inside the contracts.”

“And let's create a table of counterparties with the attributes: 'ID', 'Name' and 'Is Client?'.”
“Ok let me do this.”
After thirty seconds.
“Ok it's done.”

“Ok, let's think about what we have so far.”
“We have a table of contracts with 3 records and a table of counterparties with 6 records."
“That's correct. Question: Can you see a relationship between these two tables?”
“Yes, the counterparties in the contract table are listed in the counterparty table. And look what you can do. Instead of using the name in the contract table, you can actually use the ID of each counterparty. Can you imagine this?”

“Right, I get it. If I know the counterparty’s ID, I just look it up in the Counterparty table to find its name and anything else about it. And if the name changes later, I update it in one place only.”
“You got it! One little bonus here. The column ID in the Counterparty table is called a Primary Key. All values in this column must be unique and it can be used to create the relationship between two tables.”
“Wow. That makes perfect sense.”
“So now what do we have?”
“We have two tables representing two separate entities, contracts and counterparties; with a relationship between the attributes Counterparty 1 and Counterparty 2 to the attribute ID, the primary key of the Counterparty Table.”
“That's correct. You have two tables that are related to each other. Do you know how we call this?”
“No...?”
“A database!”
“Oh, I know that word! I thought a database was synonym of a table or a list?”
“I know, it can be confusing. Strictly speaking, a database can consist of just a single table. But most of the time, we mean a set of related tables. When those tables are linked together, we call it a relational database. And for your case, it’s probably the quickest and most practical type to implement.”
“Hmm, interesting.”
“Okay… now I’m starting to think about all the tables I’d need to create and the relationships between them. How am I supposed to keep track of all the attributes, the tables, the links?”
“That’s a very good question. And don’t worry — there are tools for this. The first step is to create what we call a data model. It’s basically a visual map of your database: the tables, their attributes, and how they connect. Let me email you a quick sketch of what yours could look like so far.”
Loïc sends an email to Tom.
“Ok, I have received your email.”

“I see. It makes sense. It's really clear.”
“The second tool you may have heard of is a data dictionary. Think of it as a structured document that explains every field in your database: what it means, what format it should follow, and what values are allowed.”
“So… like documentation?”
“Yes, it is another form of documentation. For example, imagine we have a column called ‘Status’ in the Contracts table... The data dictionary would say: 'Status' must be one of: Draft, Active, Terminated, Expired. And it would also define what ‘Active’ actually means.”
“So I would know that I have a column status, what options I can find in it and what the column means.”
“Yes exactly. Let me send you an example for your database.”

“I have just received the email. Thanks a lot Loïc.”
“You're welcome.”
“No, honestly, I feel like I’ve understood the key concepts and vocabulary of data management in less than 10 minutes.”
“Yes, and this is just the beginning of your journey! Now, I'm going to let you work because you have some data entry to do. Once you have entered the data, creating the statistics you need will only take a few minutes. Good luck!”
“Bye, Loïc.”
“Bye.”

PS: All images are AI-generated. My "virtual" friend Tom does not exist in the real world.